home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1990 / Mar 90 / MacApp.Tech$ 3⁄2⁄90 / 0773-Purging & Dehydratin-Feb90 < prev    next >
Encoding:
Text File  |  1991-03-06  |  2.6 KB  |  79 lines  |  [TEXT/GEOL]
  1. Item    3954360                         27-Feb-90        08:52PST
  2.  
  3. From:   CDA0004                         VAR Shana Corp, Don Murphy,IVR
  4.  
  5. To:     MACAPP.TECH$                    MacApp Technical
  6.         GER.XDV0002                     Germany - P1 Ges f Informatik,IVR
  7.  
  8. Sub:    Purging & Dehydrating
  9.  
  10. Attn: MacApp Technical
  11. Attn: Elmar Henne
  12. SentBy: Wayne Malkin
  13. Date   2/26/90
  14. Subject    Purging & Dehydrating
  15. From   Wayne Malkin
  16. To Elmar Henne
  17.    MacApp Technical
  18.  
  19.  Memo         Subject:Purging & Dehydrating
  20.  
  21. Elmar,
  22.  
  23. You have some interesting ideas.
  24.  
  25. References to an object would all have to be by id. It is too hard to
  26. automatically change all references to an object when the object gets purged,
  27. so storing an object's handle as an instance variable of another object is
  28. unsafe.
  29.  
  30. This means that any time you invoke a polymorphic method of an object, you
  31. will be looking up the object by its id in the method dispatcher. Any time you
  32. invoke a monomorphic method, you will be passing an id to the method as SELF.
  33.  
  34. The method dispatcher part is ok, since the method dispatcher could easily be
  35. modified to look up the object. When a monomorphic method has an id as SELF,
  36. it might get more complicated.
  37.  
  38.  
  39. 1. Assume the method dispatcher has been modified to do the appropriate lookup
  40. when it detects an ID instead of a handle. It wouldn't really need to read the
  41. object, just look up the class id. Reading the object could be handled
  42. universally by...
  43.  
  44. 2. writing a routine "LockSELF" that goes at the start of each method in a
  45. persistent object. This routine would:
  46.  
  47.   2a. Inspect the SELF at 8(A6) to see if it is handle or id,
  48.   2b. Create or rehydrate the object if required,
  49.   2c. Call the Lock method, and
  50.   2d. Change 8(A6) to the object handle so references to
  51.       instance variables within the method will work and
  52.       subsequent method calls will see a real object. (?hack?)
  53.  
  54. 3. Write a routine "UnlockSELF" that goes at the end of each method, which
  55. decrements the counter.
  56.  
  57.  
  58. Other methods are needed to determine if an object has changed and handle the
  59. writing to disk.
  60.  
  61. From the "pseudo object" thread, since we are in here in spades anyway, it
  62. might be a good idea to include the pseudo object optimization. This might
  63. also simplify the task of maintaining a decent sized object cache without
  64. infringing on other memory usage.
  65.  
  66.  
  67. Questions:
  68.  
  69. Is SELF always at 8(A6), or does it jump around?
  70.  
  71. Is it ok to rewrite the method dispatcher like this? Does this mean we forego
  72. the method dispatcher code that is in the ROM?
  73.  
  74. Is this just tooooo much of a hack?
  75.  
  76. -- Wayne Malkin
  77.  
  78.  
  79.